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1  Introduction 

Formal  methods  are  becoming  more  and  more  widely  used  in  computer  science  and  software  development. 
Specification  languages,  automatic  theorem  provers,  verification  tools  and  other  systems  based  on  formal 
mathematical  techniques  all  have  a  crucial  role  to  play.  The  need  for  formal  methods  is  especially  acute 
in  systems  which  are  safety  or  security-critical.  In  such  cases  one  failure  could  be  disastrous,  leading 
to  loss  of  life,  damage  to  the  environment,  breaches  of  national  security  etc.  In  such  cases  we  wish  to 
have  the  assurance  that  the  software  will  function  correctly. 

We  need  to  be  clear  on  the  terminology.  Software  can  be  termed  correct  only  with  respect  to  a  formal 
detailed  specification  which  describes  exactly  what  the  program  is  required  to  do.  The  objective  of 
program  verification  is  to  prove  mathematically  that  every  execution  of  the  program  will  satisfy  the 
given  specifications. 

A  hierarchical  approach  to  system  design  is  now  a  well-established  technique.  Such  an  approach  enables 
the  detailed  formal  specifications  themselves  (which  can  be  complex  and  subject  to  logical  and  other 
errors)  to  be  proved  correct  (verified)  against  a  simpler,  more  abstract  specification.  In  this  case,  we 
speak  of  design  verification.  Again,  this  specification  may  itself  need  to  be  verified  against  an  even 
simpler  and  yet  more  abstract  specification,  until  we  eventually  reach  the  formal  top-level  specification. 
The  .specifications  retiect  different  levels  of  detail  in  the  design. 

System  specifications  are  naturally  expressed  in  a  mathematical  notation,  and  the  process  of  design 
verification  uses  techniques  of  mathematical  proof:  we  construct  a  mathematical  model  of  me  system 
by  formulating  a  theory  based  on  certain  axioms,  and  proving  theorems  from  these  axioms.  The 
mathematician  may  be  content  with  —  and  convinced  by  —  paper  and  pencil  proofs.  However, 
mathematical  models  in  the  safety  and  .security  critical  world  need  to  be  subjected  to  a  greater  level 
of  rigour.  In  such  cases  an  automatic  reasoning  tool  can  help  us  formulate  the  theory,  manage  the  proofs 
of  key  results  and  avoid  logical  errors,  leading  to  increased  assurance  of  correctness. 

This  paper  is  concerned  with  the  application  of  one  such  reasoning  tool,  namely  the  Higher  Order  Logic 
(HOD  system  (developed  by  Professor  Mike  Gordon  at  University  of  Cambridge  [1])  to  the  area  of 
security  models. 

HOL  was  originally  suggested  as  a  tool  for  the  verification  of  hardware  [2].  Although  most  of  the 
activity  in  HOL  is  still  in  this  area,  HOL  has  also  been  applied  to  protocol  verification  [3],  mathematical 
theories  such  as  groups  and  integers  [4],  machine  architecture  specification  [5],  and.  most  recently,  to 
program  verification  [6].  Until  recently,  HOL  has  not  been  applied  to  security  policy  modelling  [7].  We 
believe  that  there  will  be  increased  interest  in  this  area  once  tools  for  the  study  of  concurrency  with 
HOL  become  available  [8]). 

In  order  to  verify  that  a  system  satisfies  some  notion  of  security,  the  system  needs  to  be  modelled 
mathematically  and  a  mathematical  definition  of  security  needs  to  be  formulated.  The  definition  of 
security  varies  depending  on  the  security  needs  of  the  users  of  the  system.  We  have  followed  the 
development  of  Rusliby's  general  framework  for  .security  models  [9]  which  defines  security  in  terms  of 
non-interference  —  a  system  is  secure  if  certain  processes  do  not  interfere  with  certain  other  processes, 
i.e.  they  do  not  affect  the  other  processes’  output  and  view  of  the  system. 

As  an  instance  of  this  general  theory  we  shall  give  a  detailed  treatment  of  the  Low  Water  Mark  Model 
for  security.  Although  not  a  realistic  model  of  security  because  of  its  simplicity,  the  Low  Water  Mark 
Model  has  some  interesting  features.  It  has  been  studied  by  a  number  of  authors  [10,  11,  12],  as  a  case 
study  for  a  range  of  automatic  verification  and  theorem  proving  tools. 

The  purpose  of  this  paper  is  not  to  break  new  ground  in  the  theory  of  security  models,  but  rather  to 
show  how  elTective  HOL  can  be  in  a  new  problem  domain  such  as  security.  We  shall  see  that  HOL 
can  give  useful  insights  into  this  field.  The  use  of  HOL  in  a  new  area  also  helps  us  to  highlight  HOL's 
strengths  and  weaknesses,  and  to  see  how  it  shcmld  be  extended  or  modified  to  become  more  useftil  in 
other  appiication  areas. 

In  the  next  section  we  shall  give  a  description  of  a  general  framework  for  security  models,  based  on 
[9].  ThU  is  followed  by  a  brief  description  of  the  HOL  system.  In  subsequent  secUons  we  show  how 
HOL  can  be  used  to  prove  Rushby's  general  unwinding  theorem  for  non-interference  of  processes,  and 
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consider  in  detail  the  case  of  the  Low  Water  Mark  model.  The  interacUon  with  HOL  is  described  in 
some  detail,  in  the  hope  that  readers  who  have  no  experience  of  HOL  will  be  able  to  appreciate  how 
a  medium-sized  proof  is  tackled. 

2  Security  Models 

In  terms  of  the  hierarchical  approach  referred  to  in  the  Introduction,  the  verification  of  security  require¬ 
ments  requires  that  the  top  level  specification  be  the  assertion  that  the  system  is  secure  with  respect  to 
some  definition  of  security.  This  definition  of  security  will  usually  require  a  description  of  a  general 
model  of  a  system.  This  will  involve  the  identification  of  the  types  of  the  system  entities  and  some 
abstract  functions  whose  domains  and  ranges  are  in  the  identified  types.  These  abstract  functions  are 
then  used  to  define  security. 

The  next  level  of  specification,  describing  a  particular  instance  of  the  general  system,  will  be  more 
detailed,  including  the  declaration  of  particular  operations  and  a  description  of  their  effect  on  the  system. 
Also,  the  structure  of  certain  entities  may  be  further  decomposed,  and  the  functions  which  were  abstract  at 
the  previous  level  may  be  given  concrete  definitions.  It  is  the  verification  of  this  second  level  specification 
against  a  definition  of  security  on  which  we  have  focused. 

2.1  A  General  Model 

The  security  model  of  a  system  can  be  formalized  in  many  ways.  Tliere  is  presently  much  debate 
on  what  an  appropriate  mathematical  formuladon  of  security  should  be.  Two  important  concepts 
are  deducibility  security  [13]  and  restrictiveness  [14]  addressing  such  issues  as  non-deterministic 
systems  and  for  the  latter,  under  what  conditions  secure  systems  remain  secure  when  hooked- 
up  together.  Restrictiveness  is  currently  being  modelled  in  HOL  by  Levitt  and  Alves-Foss  [7], 
who  have  proved  that  restrictivenes  satisfies  hook-up  security  and  shown  that  a  simple  distributed 
system  satisfies  restrictiveness.  In  our  work,  we  have  studied  security  in  terms  of  non-interference, 
using  the  state-based  description  which  has  been  formulated  by  Rushby  [9],  based  on  the  earlier 
work  of  Goguen  and  Meseguer  [15].  A  system  consists  of  the  following: 

•  a  set  S  of  states,  with  an  initial  state  called  initstate; 

•  a  set  P  of  processes^-, 

•  a  set  C  of  commands',  and 

•  a  set  O  of  outputs. 

We  also  have  functions 


next  :  S  X  P  X  C  —  S 
out  :  S  X  P  X  C  —  O 

Here  next{s.p,c)  denotes  the  state  of  the  system  obtained  when  the  process  p  performs  the 
command  c  in  state  s;  while  ouf(s,  p,  c)  denotes  the  output  returned  by  that  command.  Elements 
of  A  =  P  X  C  will  be  called  actions.  We  are  especially  interested  in  the  set  A*  of  action  sequences 
(here  regarded  as  lists,  for  convenience).  The  function  next  can  be  extended  to  the  function 

nextlist  :  S  x  A’  —  S 


by  defining 


next/ist(s,  Q)  =  s,  and 
nextlisi(s,h  ::  t)  =  next{nezUist{8,t),  h) 

where  []  denotes  the  empty  list,  and  h::t  denotes  the  list  with  head  A  and  tall  /.  We  also  define 
the  functions 

do:A'—S 
result  ;  A*  X  A  — »  O 

For  the  Mkc  ct  gcMnliiy  we  uee  pnetsm  *s  the  aettve  eaeati  raUwr  Oiaa  mm  u  need  by  Riuhby. 
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by  the  equations 

£/o(a)  =  nextlist{initstate,a), 
result(Q,p,c)  =  out(do{a),  p,c) 

Thus  yields  the  state  reached  after  performing  the  action  sequence  o,  while  rfsuU((t.p.  c] 
gives  the  output  when  process  p  does  command  c  after  action  sequence  a. 

As  a  result  of  the  outputs  of  some  sequence  of  actions  performed  starting  from  the  inittal  state 
of  the  system,  a  process  will  have  a  view  of  each  of  the  states  that  have  been  reached.  Formally, 
we  have  a  function 

view  :  P  X  S  —  'S 

where  ^  is  some  (as  yet  unspecified)  set  of  private  states.  At  the  top  level  of  specification  it  is 
possible  to  give  a  formal  definition  of  security  without  defining  what  states,  outputs  and  views 
look  like  or  how  a  state  is  changed  by  an  action. 

A  process  pi  is  said  to  be  non-interfering  with  another  process  pi  if  the  results  seen  by  the  process 
P2  after  any  sequence  of  actions  is  the  same  regardless  of  whether  process  pi  performed  some  of 
the  actions  or  not.  Formally: 

I  t  siill{(t .  pj.c)  =  I  f  .sHH{ct/pi.  pi.v)  Vi>  S  -T'  ,  (•  6  C 

where  a/p  denotes  the  sublist  of  a  formed  by  deleting  all  actions  consisting  of  commands 
performed  by  the  process  p. 

A  definition  of  security  can  be  formulated  by  firstly  declaring  some  relation  R  on  processes  (called 
a  security  policy  by  Rushby).  where  R  (pi,  pi)  is  interpreted  to  mean  that  information  is  allowed 
to  flow  from  process  p:  to  process  p/.  We  shall  say  that  the  system  is  secure  with  respect  to  a 
policy  R  if  p:  is  non-interfering  with  pi  whenever  R  (pi  .pi)  is  not  true.  In  other  words,  if  no 
information  is  allowed  to  flow  from  pz  to  pi,  then  pi  should  ne  unaffected  by  whatever  pz  does. 

At  this  level  of  detail  it  is  not  possible  to  prove  security  with  respect  to  non-interference  because 
the  concept  of  a  view  has  not  been  formally  defined.  However,  it  is  possible  to  prove  certain 
theorems,  including  an  unwinding  theorem  which  states  that  if  a  given  definition  of  the  view  of 
a  process  satisfies  certain  conditions  then  the  system  is  secure.  These  conditions  are  intended  to 
be  simpler  to  prove  and  thus,  once  the  system  is  described  in  more  detail  at  the  second  level 
of  specification,  only  these  conditions  need  to  be  proved  rather  than  proving  security  from  first 
principles. 

Before  we  give  the  formal  statement  of  the  unwinding  theorem,  we  make  the  following  definition. 
Wc  say  that  the  system  is  internally  consi.steni  if 

view(p,  s)  =  view(p,  t)  =>  oHt{s.p.  c)  =  out{t,p,c)  'ip  ^  P.  s,  (  €  h’.  c  €  C. 

which  expresses  the  fact  that,  if  a  process  p's  view  of  two  states  s  and  t  is  the  same,  then  the 
outputs  of  commands  performed  by  p  will  always  be  identical  for  these  states. 

The  unwinding  theorem  is  as  follows  [9): 

Theorem:  Let  M  be  an  internally  consistent  system  with  a  security  policy  R  such  that 

(1)  /2(pi,pi)  view{p2,next{s,pi,c))  =  view{p2,s) 

(2)  view(pi,s)  =  view(pi,l)  ^  view{pi,next{s,p2,c))  =  «;iew(pi,next(t,pj,c)) 

Vpi ,P7^  P<  *€5,  c6C 

Then  M  is  secure  (with  respect  to  the  policy  R). 

The  proof  of  this  theorem  is  straightforward,  and  may  be  found  in  [9]. 

— 
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It  IS  useful  to  prove  this  unwinding  theorem  at  the  most  abstract  level  possible,  because  it  can 
then  be  applied  to  many  different  descriptions  of  systems  which  may  have  different  definitions 
for  states,  operations,  outputs  and  views  but  which,  nevertheless,  satisfy  the  sufficiency  conditions 
for  security  according  to  the  unwinding  theorem.  There  are  many  different  versions  of  unwinding 
theorems  but.  as  hinted  by  their  name,  they  reduce  the  problem  of  security  from  proving  certain 
assertions  about  sequences  of  actions  to  proving  assertions  about  single  actions. 

In  Section  4  the  top  level  model  of  the  system  is  set  up  within  HOL  and  the  unwinding  theorem 
is  proved. 

The  next  level  of  specification  describes  the  system  in  more  detail  by  giving  definitions  to  states, 
operations,  actions  (and  their  effect  on  states),  outputs  of  actions,  views,  and  a  security  policy. 
This  description  can  still  be  general  in  that  many  real  systems  may  satisfy  the  definitions;  but, 
because  it  is  less  abstract  than  the  top  level  description,  it  characterises  a  proper  subset  of  the  set 
of  possible  systems  described  by  the  top  level  model.  One  such  lower  level  model  is  the  Low 
Water  Mark  Model. 


2.2  The  Low  Water  Mark  Model 

This  model  describes  a  system  consisting  of  a  set  of  processes,  a  non-empty  set  of  data  objects  and 
three  -'perations  used  by  the  processes  to  access  the  data  objects.  Associated  with  each  data  object 
is  a  classification  which  is  a  member  of  .set  of  values  called  levels.  Associated  with  each  process 
IS  a  clearance  level  which  is  also  a  member  of  this  set.  On  tliis  set  of  levels  there  exists  a  relation 
which  will  be  called  dominates,  where  “dominates(x.y)”  means  that  x  has  a  higher  security  level 
than  y.  It  is  assumed  that  this  relation  is  a  partial  ordering,  i.e.  it  is  reflexive,  antisymmetric  and 
transitive.  We  shall  assume  that  there  is  a  special  level,  called  system  high,  which  dominates 
all  other  levels.  A  state  can  be  described  as  a  mapping  from  data  object  identifiers  to  the  pair 
consisting  of  the  contents  of  the  data  object  and  the  classification  of  the  object. 

The  three  operations  are  reading  the  contents  of  a  data  object,  overwriting  the  contents  of  a  data 
object,  and  resetting  the  classification  of  an  object  to  system  high.  The  effect  and  output  of  an 
operation  on  a  data  object  performed  by  a  process  is  dependent  on  the  relationship  between  the 
classification  of  the  object  and  the  clearance  of  the  process.  The  effect  and  output  of  each  of  the 
three  operations  paired  with  a  process  are; 

1  READ 

The  state  of  the  system  remains  the  same  after  a  process  has  read  the  contents  of 
an  object.  If  the  clearance  of  the  process  dominates  the  classification  of  the  object, 
then  the  output  signals  that  the  read  was  successful  and  the  contents  of  the  object  are 
displayed.  Otherwise,  the  output  signals  that  the  read  was  unsuccessful  and  no  other 
information  is  displayed. 

2.  WRITE 

If  the  classification  of  the  object  dominates  the  clearance  of  the  process  then  the  new 
state  after  a  write  remains  the  same,  except  that  the  identifier  of  the  object  which  was 
overwritten  is  now  mapped  to  the  pair  consisting  of  the  new  data  and  the  clearance 
of  the  process.  Otherwise,  the  slate  remains  the  same  and  the  output  signals  an 
unsuccessful  write. 

3.  RESET 

If  the  classification  of  the  object  dominates  the  clearance  of  the  process  then  the  new 
state  after  a  reset  remains  the  same,  except  that  the  data  object’s  contents  are  cleared 
and  its  classification  is  now  set  to  system  high.  Otherwise,  the  state  remains  the  same 
and  the  output  signals  an  unsuccessful  reset. 

The  model  is  called  the  Low  Water  Mark  Model  because  a  data  object’s  classification  can  only 
be  increased  by  a  reset  operation,  which  will  set  it  to  system  bilk. 


1 


I 


ERL*0577-RR 


The  unwinding  theorem  can  be  used  to  prove  the  security  of  the  Low  Water  Mark  Model  given 
the  additional  assumption  that  the  ordering  dominates  is  a  total  relation,  that  is,  given  any  two 
levels,  one  must  dominate  the  other.  An  unwinding  theorem  specific  to  this  model  was  derived 
by  Billard  in  [16], 

Before  formulating  the  above  theory  in  HOL.  we  shall  give  a  brief  overview  of  the  HOL  system. 


3  The  HOL  System 

The  HOL  system  is  large  and  complex,  and  it  is  beyond  the  scope  of  this  paper  to  describe  it  fully. 
We  refer  the  reader  to  the  HOL  manuals  [4]  for  more  details.  In  the  following,  we  shall  attempt  to 
give  a  tiavour  of  working  with  HOL,  as  well  as  highlighting  those  feamres  of  the  system  relevant  for 
reasoning  about  security  models. 

HOL  supports  interactive  theorem  proving  in  higher  order  logic.  It  provides  a  natural  and  highly 
expressive  way  of  specifying  and  reasoning  about  models  of  abstract  systems  —  as  well  as  mathematical 
theories  in  general.  It  inherits  many  ideas  from  the  earlier  LCF  theorem  prover  developed  by  Robin  Milner 
and  collaborators  in  the  early  1970's  [17].  As  in  LCF.  the  programming  language  ML  (ML  stands  for 
Meta-Language)  provides  the  environment  in  which  terms  and  theorems  of  the  logic  are  denoted  and 
theorem  proving  takes  place.  We  shall  assume  that  the  reader  has  some  familiarity  with  ML  (see  [18] 
for  an  elementary  introduction). 

HOL  IS  really  a  proof-assistant  and  proof  checker.  It  will  not  prove  complex  theorems  automatically;  the 
user  must  have  an  idea  of  the  way  the  proof  will  work,  and  apply  the  appropriate  steps  (called  tactics)  in 
the  proof,  which  proceeds  in  a  goal-directed  fashion.  The  HOL  system  manages  the  proof,  taking  care 
of  the  details  of  primitive  proof  steps,  and  provides  a  sound  theorem  proving  environment  —  i.e.  the 
user  is  assured  that  a  theorem,  once  obtained,  is  true  within  the  logic. 

3.1  The  HOL  Logic 

The  HOL  logic  is  a  version  of  higher  order  logic  based  on  Church's  formulation  of  simple  type 
theory  [19].  It  is  a  variant  of  typed  polymorphic  A-calculus.  with  formulae  being  identified  with 
terms  of  boolean  type.  Variables  can  range  over  functions  and  predicates,  and  functions  can  take 
other  functions  as  arguments  (hence  'higher  order'). 

Terms  of  the  HOL  logic  have  the  ML  type  called  term,  and  are  input  to  HOL  enclosed  in  quotation 
marks.  The  following  table,  adapted  from  [4],  summarises  the  primitive  terms  of  the  logic: 

Table  1  Primitive  Terms  of  the  HOL  Logic 


Kind  of  term 

HOL  Notation 

Description 

Variable 

"var :  <t  ' 

variable  var  of  type  a 

Constant 

"const :  <r  " 

constant  of  type  a 

Combination 

"t  t'  '• 

function  t  applied  to  i' 

Abstfaction 

"\x.  t  ■■ 

lambda  expression 

From  these  primitive  terms  are  built  the  usual  logical  constructs,  as  follows: 


Table  2  [)erived  Logical  Constructs  of  HOL 


Kind  of  term 

HOL  NotaUon 

Description 

Truth 

»» 

true 

Falsity 

-P" 

false 
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Table  2  (Continued)  Derived  Logical  Constructs  of  HOL 


Kind  of  term 

HOL  Notation 

Description 

Negation 

"‘t  ■' 

not  t 

Disjunction 

"t  V  t'  •• 

t  or  t' 

Conjunction 

"t  A  t'  " 

t  and  t' 

Implication 

"t  ==>  t'  " 

t  implies  t' 

Equality 

"t  =  t'  •' 

t  equals  t' 

Universal  Quantification 

•■’x.t  •• 

for  all  X  :  t 

Existential  Quantification 

"?x.t  •• 

there  exists  an  x  such  that  t 

Unique  Existential 
Quantification 

•■?!x.t" 

there  exists  a  unique  x  such 
that  t 

f-term 

"@x.t " 

an  X  such  that  t 

Conditional 

t  =>  t'  1 1"  ■■ 

if  t  then  t'  else  t" 

The  types  of  HOL  terms  have  the  ML  type  called  type,  and  can  take  the  following  forms: 


Table  3  HOL  Types 


Kind  of  Type 

HOL  Notation 

Description 

Type  variable 

";*a" 

arbitrary  type 

Type  constant 

"'.bool " 

fixed  type 

Function  type 

":(r  ->  (t' 

functions  from  <t  to  o' 

Compound  type 

. <T„)  op" 

general  type  constructor 

Any  term  input  to  the  system  must  be  well-typed  according  to  the  rules  of  the  logic.  HOL  has  a 
type  checker  for  logical  terms  based  on  the  ML  type  checking  algorithm. 

3.2  Proving  Theorems  in  HOL 

While  interacting  with  the  HOL  system  the  user  is  working  with  an  object  called  a  theory.  A 
theory  consi.sts  of  types,  constants,  definitions  and  axioms.  It  also  contains  an  explicit  list  of 
those  theorems  which  have  so  far  been  proved.  A  theorem  is  represented  in  HOL  by  a  value  of 
ML  type  thw.  The  system  is  sound  in  that  tlieonly  way  to  obtain  theorems  is  by  generating  a 
proof.  This  is  done  by  applying  ML  functions  representing  inference  rules,  either  to  axioms  or 
previously  generated  theorems.'  Theorems  are  denoted  generally  by  F  I-  t,  where  F  is  a  set  of 
boolean  terms  called  assumixions,  and  t  is  a  boolean  term  called  the  conclusion.  If  F  is  empty, 
we  write  simply  h  t. 

The  HOL  logic  itself  has  five  axioms  and  eight  primitive  inference  rules,  along  with  a  vast  number 
of  derived  theorems  and  inference  rules.  The  HOL  system  is  provided  with  a  number  of  built-in 
theories  (such  as  bool,  pair  and  Ibt),  as  well  as  a  set  of  useful  library  theories  (such  as  sets, 
string,  integer  etc)  which  can  be  called  upon  at  will. 

In  practice,  proofs  are  not  carried  out  forwards,  but  in  a  more  natural  goal-directed  fashion  invented 
by  Robin  Milner  for  LCP.  Milner  invented  the  notion  of  taaics.  A  tactic  is  an  ML  function  which 


1.  reduces  a  goal  to  subgoals,  and 

2.  remembers  the  reason  why  solving  the  subgoals  will  solve  the  goal. 
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For  example,  suppose  we  want  to  prove  the  formula  A  A  B.  Then  the  goal-directed  approach  says 
that  It  is  enough  to  prove  the  subgoals  A  and  B,  because  we  know  that  from  F  A  and  l-  B  we 
can  deduce  the  theorem  t-  A  A  B. 

HOL  has  an  extensive  subgoal  package  for  managing  goal-directed  proofs.  Becoming  a  HOL 
expert  means  becoming  familiar  with  a  range  of  tactics,  and  the  situations  where  they  can  be 
applied.  New  tactics  can  be  programmed  in  ML,  or  (more  easily)  built  up  from  existing  tactics 
by  means  of  special  functions  called  tacticah.  Quite  powerful  and  sophisticated  tactics  ( which  we 
might  term  strategies)  can  be  tailor-made  for  the  problem  domain  being  studied. 


4  A  Theory  of  Security  in  HOL 

In  this  section  we  shall  show  how  to  formalise  within  HOL  the  general  theory  of  security  which  was 
described  in  Section  2.  We  describe,  at  the  top  level  of  abstraction,  the  specification  of  non-interference 
and  security,  and  the  interactive  proof  of  the  unwinding  theorem  in  HOL. 

4.1  T^pe  and  Constant  Definitions 

We  begin  the  interaction  with  HOL  by  creating  a  new  HOL  theory  called  ‘security'.  Within  this 
theory  all  the  entities,  tunctions  and  relations  for  the  general  system  are  expres.sed  formally  in 
the  higher  order  language  of  HOL.  Firstly,  all  the  necessary  types  need  to  be  declared  by  means 
of  the  following  ML  commands  (the  symbol  #  is  the  HOL  prompt,  and  the  HOL  responses  are 
suppressed). 


*r. 


C-?  ■'  'process'; 
r-?  ■>  '  r<:rrjnar.d'  ; 
pe  '  '  ;  ; 

pe  ■  ' private^ata" 
r.-*_abcr-av  ■  ' 


'pcliry' , 


“  :prr  re'SS#c::?.T:ar.d"  :  :  ; 
“:pr:ress  prirress  -> 


The  first  five  types  are  declared  as  abstract  types  because,  at  this  level  of  detail,  there  is  no  further 
information  on  the  nature  of  the  objects  in  these  sets.  However,  we  do  know  that  an  action  is  a  pair 
consisting  of  a  process  and  a  command,  and  that  a  policy  is  a  relation  on  processes.  Therefore, 
these  types  can  be  defined  in  terms  of  the  abstract  types. 

We  also  need  to  declare  the  primitive  constants  of  the  system  (note  that,  in  higher  order  logic, 
functions  are  also  constants).  The  values  of  the  view  function  are  taken  to  be  of  the  type 
private_stace. 


»new_constar.!;  :  '  iriiPscace' ,  state "  i  ;  ; 
#riew_.ron3t3rit  'next',  '•:scace  ->  artitn 
#new_'or.3tant  :'ooC',  ’:state  ->  action 
»new_.r  ; r.stant  :  '  view '  ,  •  : pro-ress  ->  state 


->  state"  '  ;  ; 

>  output “ )  :  ; 

->  privace_3t  .ate" 


The  functions  defined  in  Section  2  are  now  easily  expressed  in  HOL.  The  following  interaction 
with  HOL  shows  how  nextlisc  is  defined  in  NO.,  and  also  HOL’s  'reply'  once  the  definition  is 
accepted.  Note  that' next  list  is  defined  recursively  on  action  lists.  Proofs  involving  recursively 
defined  functions  will  typically  involve  induction  on  the  recursive  type. 


let  NEXTLIST_DEF  =  new_lisc_rec_def inition  ( 'NEXTLIST_DEF' , 
"(nexClist  (s:scace)  (( 1 : (action) list )  =  s)  /\ 

(nextlist  s  (CONS  h  t)  *  next  (nextlist  s  t)  h) " ) ; ; 
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To  make  what  follows  more  readable,  from  here  on  we  shall  only  show  the  HOL  responses  to 
new  user  definitions.  The  functions  do  and  result  are  defined  as  follows: 


-  lalist.  do  alist  =  r.exclisc  init-state  ilisc 


.-E!£VlT_rEr  =  I-  fdlisc  a.  rer^ul^  alisc  a  =  ~uC'do  alist:,a 


Since  the  definition  of  non-interference  involves  a  comparison  of  two  lists  of  actions  —  one  of 
which  is  a  sublist  of  the  other  —  we  define  a  function  filter  which,  given  the  original  action 
list  and  process,  will  return  the  appropriate  sublist.  It  is  then  possible  to  define  non-interference 
conci.sely. 


We  ,ve  now  in  a  position  to  define  security  with  respect  to  net-interference  for  an  arbrnary 
security  policy  R: 


r.r  = 
secure 


R  = 


-eres  3-.  pj 


The  definition  of  internal  consistency  is  as  follows: 


::jtefnally_consistent_:ef  = 

-  ir:C-?rna  1  iy_r  :r.3  istent  = 

's  c  p.  view  p  i  =  view  p  t =  =  > 
iijt  3  p,  :  =  -It  t'p,c!)) 


This  completes  the  specification  of  the  general  system  for  security.  As  can  be  seen,  it  is  quite  easy 
to  formalise  it  in  HOL.  There  are  a  number  of  reasons  for  this.  Firstly,  the  higher  order  capability 
tf  HOL  means  that  we  have  no  difficulty  in  defining  concepts  such  as  security,  where  we  need  to 
quantify  over  a  predicate  R  (the  security  policy).  Secondly,  the  fact  that  the  HOL  logic  is  strongly 
typed  means  that  many  trivial  errors  in  setting  up  the  specification  can  be  avoided.  Thirdly,  it  is 
easy  to  define  new  ftinctioni  on  recursive  types  such  as  ncxtlisc. 
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4.2  An  Interactive  Proof 

Having  set  up  the  basic  theory,  we  can  now  prove  the  unwinding  theorem  using  HOL's  subgoal 
package,  which  enables  a  user  to  develop  a  goal-directed  proof  interactively  by  issuing  commands 
(tactics)  which  produce  new  subgoals.  The  package  manages  the  proof  by  recording  which 
subgoals  still  need  to  be  proved  in  order  to  prove  the  original  goal. 

To  carry  out  the  proof,  we  use  a  lemma  called  UNAFFECTED_VIEW_LEMMA: 

■-•>;AFFECTED_V:EW_LE;.tMA  = 

—  !  P.  . 

i.r.cer.’ially_'cnsistenC  /\ 

I  pi  ?2. 

S  pi  p2  ==> 

lali3P.vi.aw  p2(doi  filter  alisc  pi.;  =  view  pi  i-  alut 
==>  secure  R 

This  lemma  asserts  that,  if  information  flow  from  process  pi  to  process  p2  is  not  allowed  according 
to  a  policy  R,  then  p2’s  view  should  not  be  affected  by  commands  performed  by  pi.  The  proof 
of  this  lemma  is  short  and  straightforward,  and  is  included  in  Appendix  A. 

The  proof  of  the  unwinding  theorem  begins  by  setting  the  top  goal  to  the  HOL  formulation  of 
the  theorem  using  the  definitions  above. 

sc  '!  ,P:r:liiy  irif err.ally_ccr.sisreriC 


Is  1.  view  pi  inexc  s  pl.c, .  =  view  p‘ 
.St.  view  pi  3  =  view  pi  t)  ==> 

It  p2 .  view  pi  :nexc  s  -pl.c.;;  = 

view  pi  .next  t  p-.ci; 

‘■"’I  r**  R  "  ;  ; 


:r.*:err.aily_:  :r;3  \ 

R  pi  p:  ==> 

'3  view  pi  r.ext  sfpl.Oi  =  view  pi  s; 

■ 'pi  3  C. 

(view  pi  3  =  view  pi  t)  ==> 

(!c  p2.  view  pl'ne.xt  s(p2,:i!  = 

view  pl.r.exc  C(p2,cli))i  =  =  >  secure  R" 


Firstly,  the  goal  is  decomposed  to  its  simplest  form  which  requires  secure  R  to  be  proved  with 
the  three  conditions  as  assumptions.  For  this  we  use  the  standard  tactic  REPEAT  (  stri  p_tac  ) . 
which  breaks  apart  conjunctions  and  implications,  and  removes  outermost  quantifiers.  We  can  then 
use  the  above  lemma,  which  has  as  its  consequence  secure  R.  Therefore,  if  we  can  show  that 
the  conditions  in  UNAFFECTED_viEW_LEMMA  can  be  proved,  we  shall  have  solved  the  goal. 
These  conditions  of  the  lemma  replace  the  goal  if  we  use  the  tactic  MATCH_MP_TAC. 

These  proof  steps  are  combined  into  one  tactic  by  using  the  tactical  then.  In  general,  tael  then 
tael  will  apply  tad  to  the  current  subgoal  and  then  apply  tac2  to  all  resulting  subgoals. 

In  the  following  interactions  with  HOL.  the  current  assumptions  are  listed  below  the  goal  and 
each  one  is  delimited  by  square  brackets.  Assumptions  are  numbered  from  one,  starting  at  the 
bottom  of  the  list  as  displayed. 

»e( REPEAT  STRIP_TAC  THEN 

MATCH_HP_TAC  UNAFFECTED_VIEW_LEMMA1 : ; 
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“  ir.'ern^llV'-- -■''sio'enc  .  ' 

!  p  1  p  2  . 

Islisc.  view  p2 '.do  (  filter  .ilist  cl': 

=  view  p2:do  alistl:)' 

"  ir.cerr.a  ily_con3istenc  “  i 
[  " ! pi  p2 .  R  pi  p2  ==> 

,!3  t.  view  p2  ■  next  s'pl.O)  =  view  p2  s  i  “  ] 

''view  pi  3  =  view  pi  1 1  =  =  > 

;!c  p2 .  view  plinext  slp2,c)) 

=  view  plinext  C(p2,c))i)"  ] 


The  conjunct  internally_consistent  can  be  solved  simply  by  rewriting  with  the  assump¬ 
tions.  using  the  HOL  tactic  ASM_REWRITE_TAC.  In  order  to  prove  the  other  conjunct,  our  first 
impulse  might  be  to  apply  REPEAT  STRIP_TAC.  However,  we  wish  to  apply  the  induction 
principle  to  the  action  list  al.  and  for  this  the  goal  needs  to  be  universally  quantified  over  this 
term.  REPEAT  STRIP_TAC  would  strip  away  too  much;  instead  the  two  outer  quantifications 
are  stripped  using  GEN_TAC  and  the  implication  is  decomposed  in  two  steps. 


ASM_FSWFIT£_T.a.c:’,  -lEN 

FEFE.AT  3EM_T.AC  THEN 


al:.3f.  vie-w 


?1 , 


Is  :.  c2  r.^xr  sipl,:ii  =  view  p2  s)  "  i 

■'pi  3  f  . 

,view  pi  3  =  view  pi  ■ )  ==> 
i!c  p2 .  view  plir.exc  s(p2,c)) 

=  view  pi (next  t;p2,sl)l)’  ) 

"F,  pi  p2-  i 


The  term  is  now  in  the  form  where  we  can  apply  the  induction  lactic  for  lists,  producing  two 
subgoals  —  one  for  the  base  case  of  an  empty  list  and  one  for  the  inductive  step. 


■te  (LIST_INDUCT_TAC)  ;  ; 

OK  .  . 

2  subgoals 

•ih.  view  p2  ( do  (£  i  Iter  (CONS  h  alistlpD)  = 

view  p2 (do (CONS  h  alistl)" 

L  “ internally_consistent ■  1 
[  ’ Ipl  p2 . 

R  pi  p2  ==> 

(!s  c.  view  p2 (next  s(pl,cl)  =  view  p2  s) ’  ] 

[  (  !  pi  S  t  . 

(view  pi  s  =  view  pi  t)  ==> 

(!c  p2.  view  pKnext  s(p2,c)) 

=  view  pi (next  t(p2,c))))’  1 

(  "R  pi  p2-  1 

(  ’view  p2 (do (filter  alist  pi) )  *  view  p2(do  alist)*  ) 
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view  pi  3  =  view  pi  t:  ==> 

I  3  p2  .  view  pliTiexC  3'. p2,c]i 


=  view  pi  next  t ■ p2 , r l ! j i '  ; 

L  “R  pi  ?2'  ] 

The  subgoaJ  for  the  base  case  is  easily  solved  by  rewriting  with  the  definition  of  filter  since 
filter  []  pi  =  [].To  make  progress  on  the  subgoal  for  the  inductive  step,  it  can  also  be 
rewritten  with  the  definition  of  filter: 

#e  ;  REWRITE.TAC  [r  :LTEP._DE?;  )  ;  ; 


view  pi; dci  EST  h  =  pi.  => 

filter  ilist  pi  ■  EONS  hi  filter  alist  pi)  .' 
■.‘lew  p  1  i d-t ! C IMS  h  a  1 )  '  ‘ 


.text 


a  ,pl,  r; 


;  ■  view  pi  .  i;. ;  filter  ali3C  ?!:■ 

=  view  p2 ido  alist  *  ; 

This  term  can  be  simplified  by  stripping  the  outer  quantifier  and  removing  the  conditional 
expression  by  performing  case  analysis  on  FST  h  =  pi.  It  is  possible  to  expand  the  two 
resulting  subgoals  by  rewriting  with  the  definitions  of  do  and  nextlist.  This  will  remove 
occurrences  of  CONS  and  introduce  occurrences  of  next  enabling  the  term  to  be  matched  later 
on  with  consequences  of  assumptions.  The  tactical  THEN  is  very  useful  here,  since  the  resulting 
subgoals  are  of  the  same  form  and  can  thus  be  simplified  or  solved  by  the  same  tactics. 

s-a,GEN_TAC  THEM  Cl  NC_  :A3ES_TAC  THEN 

fewrite_t.ac::i’_:ef::;e:itlist_defi  > .- 


_  ^ubgoals 

"view  p2 (next tnextlisc  initstace ( f i Iter  alist  pljlhl  = 
view  p2  1  next  ! nextlist  initstate  alisoh)' 

(  ■  iriterr.a  lly_  jcnsistent  ■  ) 

:  ■ !pl  P2 • 

R  pi  p_  ==> 

:!$  r.  view  pi'.next  3(pi,;)l  =  view  p2  si"  ; 

1  i !pl  s  t  . 

iview  pi  s  =  view  pi  t)  ==> 

( .' c  p2  .  view  pi  (next  s(p2,c)) 

=  view  pi (next  t(p2,c))))"  ) 

[  ’R  pi  p2-  1 

[  "view  p2(do(filter  alist  pi)) 

s  view  p2 (do  alist)*  ] 

[  ■ (FST  h  =  pi)  =  F*  1 
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r 


'  ■  1  "tW 


p2  r: *5X^11  SC  cnitscace  i  filter  alisc  pi 
pw  r.exc  riexclisc  iriicscace  alisc  r. .  “ 


rcnsiscenc 


•  C'  *■  • 

F  pi  p2  =^> 

.  ! s  7 .  view  p2  .next  s 'pi , r  ;  =  view  pi  s ' “ 

!  p  1  S  . 

.view  pi  3  =  view  pi  z\  ==> 

!i  pi.  view  pi (next  3ip2,r;i 

=  view  pl.;r.exc  C;p2,c):;)"  i 

“R  pi  p2‘  ! 

[  "view  p2!doi filter  alist  pi)! 

=  view  p2 (do  alist!”  i 

'  “  r 3T  h  =  pi )  =  T"  I 


At  this  point  we  shall  concentrate  on  proving  the  first  (i.e.  bottom)  subgoal.  The  proof  of  the 
second  subgoal  will  follow  the  same  steps.  Now  that  the  definition  of  next  list  has  been  used 
to  remove  occurrences  of  CONS,  the  goal  is  more  readable  if  the  terms  of  the  form  next  list 
initstate  al  (where  al  is  an  action  list)  are  rewritten  in  terms  of  do.  We  use  our  own 
inference  rule  SYM_GEN,  which  takes  theorems  of  the  form  t-  !xi  ...  x,,.  tl  =  t2  and  gives 
the  theorem  I-  !xi  ...  x„.  t2  =  tl.  The  goal  is  also  rewritten  using  the  second  assumption.  We 
then  use  the  powerful  tactic  RES_TAC,  which  searches  for  assumptions  of  the  form  A  B  and 
attempts  to  match  A  against  other  assumptions,  using  modus  ponens  to  produce  new  assumptions 
matching  B. 


3*? 


:£r!  THEN'  RES 


p-  r**?xc  .do  alisc  h.^  =  view 


view  p»  :r.exc 


=  view  c2 


view  pi  s  =  view  pi  -  =  =  > 

,fc  p2.  view  pi (next  3(p2,7)) 

=  view  pi (next  C ( p2 , c) ) !) *  ] 

;  "R  pi  p2"  1 

;  'view  p2  (do filler  alisc  pi!) 

=  view  p2ido  alisP' '  ! 

:  "  ■'  FST  h  =  pH  =  T-  ! 

[  "!s  c.  view  p2 next  s:pi,r)i  =  view  p2  s'  ] 

;  " ! t  p2 '  . 

view  p2  'r.ext  :d;  1 1 1 rt  ■  , p2  '  ,  r  .  = 

view  p2  i  r.e.xt  ■  lo  .  f  i  Iter  alisC  pi )  '  ;  p2  '  .  c  i  ■  '  ’ 


The  second  assumption,  together  with  the  fact  that  the  first  component  of  h  is  pi  (the  third 
assumption)  will  solve  the  goal.  Although  this  seems  a  fairly  straightforward  step,  it  requires 
fine  manipulation  of  some  of  the  assumptions  and  careful  rewriting  which  is  performed  by  the 
following  compound  tactic: 

>te(  (REWRITE_ASM_TAC  (1  4  ())  THEN 

ONCE_REWRITE_TAC(PAIR_hl  THEN 
PURE_ASM_REWRITE_TAC ( 1  THEN 
REWRITE_TAC(1 ) ; ; 

OK.  . 

goal  proved 

.  I-  view  p2 (next (nexc list  initstate  alist)h)  = 

view  p2(nexclist  initstate!  filter  alist  pD) 


( 
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This  completes  the  proof  of  the  first  subgoal  of  the  case  analysis  step  we  performed  earlier.  The 
second  subgoal  can  be  proved  along  similar  lines,  thus  solving  our  original  goal  and  proving  the 
desired  theorem.  As  a  final  step,  we  add  it  to  the  current  theory,  and  bind  it  to  the  ML  identifier 
UNWINDING_THM. 


=  vi^w  pi  r.-5xt  c  ■  p_  ,  '  ■  =  =  > 


pr 'ved 


al-iC  n.’Wi:iDIN’G_7HM 


The  full  details  of  the  proof  are  given  in  Appendix  A. 


5  Proof  of  Security  for  the  Low  Water  Mark  Model 

Given  the  general  theory  of  security  developed  in  the  previous  section,  it  is  possible  to  prove  in  HOL 
that  a  particular  system  is  secure.  In  this  section,  we  shall  describe  the  proof  of  security  for  the  Low 
Water  Mark  Model  using  the  unwinding  theorem. 

It  IS  not  possible  in  HOL  to  use  UNWINDING_THM  as  it  stands,  because  the  types  coranand,  object, 
state,  output  and  the  functions  next  and  out  now  need  to  be  given  concrete  definitions  instead 
of  being  abstract.  A  new  theory  needs  to  be  created  where  these  types  and  constants  (along  with  other 
types  and  constants)  are  defined.  The  unwinding  theorem,  including  the  auxiliary  lemma,  needs  to  be 
reproved  (although  this  is  straightforward,  being  essentially  automatic).  This  highlights  a  problem  with 
HOL’s  treatment  of  theories.  Ideally,  we  would  like  to  be  able  to  instantiate  the  original  theory  by  giving 
some  of  the  abstract  types  and  constants  of  that  theory  concrete  definitions  and  automatically  inheriting 
the  theorems  of  the  original  theory.  However,  the  HOL  system  does  not  as  yet  provide  a  mechanism 
for  doing  this. 
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5.1  Type  and  Constant  Definitions 

We  give  below  the  definitions  of  some  of  the  types  which  were  abstract  in  the  general  security 
theory,  and  some  further  types  which  are  needed  to  describe  the  Low  Water  Mark  Model.  The 
data  objects  of  the  system  have  the  type  object  which  is  a  pair  consisting  of  its  contents  of  type 
data  and  its  classification  of  type  level.  The  states  of  the  system  are  considered  to  be  mappings 
from  the  type  filename,  which  is  the  set  of  data  object  identifiers,  to  the  type  object.  The 
output  of  a  command  is  considered  to  be  a  pair  consisting  of  some  data  and  a  boolean  value 
intended  to  indicate  whether  the  command  was  successful  or  not. 

riew_v/pe  0  '  level '  ;  ; 

.•^.ew_-ype  1'  'iaCa';; 
r;ew_tyce  1  'process':; 
r.ew_‘;ype  1  'filename';; 

new_fype_abbrev  ''object',  "  :data#level'‘ )  ;  ; 
r.ew_type_abbrev  .'state',  filename  ->  object");; 
r.e'A;_"ype_abbrev  ,  '  output '  ,  “  :d3ta»bool" )  ;  ; 

The  type  command  is  defined  using  HOL's  type  definition  package,  due  to  Tom  Melham.  This  is 
an  extremely  useful  facility  (with  some  ftindamental  limitations  which  will  not  concern  us  here). 
It  is  ideally  suited  to  defining  new  recursive  and  compound  types,  because  it  will  automatically 
provide  a  number  of  useful  theorems,  including  an  induction  theorem.  It  will  also  provide  a  tactic 
which  reduces  the  proof  of  a  goal  with  a  universally  quantified  variable  of  recursive  type  to  a 
proof  of  the  goal  for  elements  of  the  base  type  and  a  proof  of  the  inductive  step  for  the  recursively 
structured  elements  of  the  type.  In  this  case,  the  type  command  is  not  recursive,  but  it  is  still 
a  good  idea  to  use  the  type  definition  package  to  produce  a  tactic  which  splits  a  goal  which  is 
an  assertion  about  commands  to  three  subgoals,  one  for  each  type  of  command  —  read,  write 
and  reset. 


-m.T3r.f_.4xi.  rm  =  f -ef  ire_f/pe  '  rcrjr.ard_Axf  rm ' 
:  TT^r.d  =  rEAD  filename  ■ 

aKITE  dafa  fii'ina.Tie  • 
rEEET  f  f  le.rame '  ;  ; 


•  T.~.ird_.4.'<irm  = 


! f .  :n(READ  f,  =  fO  f j 

!d  f.  fr.  (WRITE  d  f:  =  fl  d  f)  ,' \ 

■If.  fni RESET  f '  =  Z2  t: 

IjMMAND.CASES.THM  = 

pr  :ve_ir.ducf  iDn_chm  : ;:rJ'.ar.d_.4xicm;  ; 
::.MMAJJD_TA3ES_THM  = 

t  ? 

!f.  P':READ  fi)  ,\  'I’d  f.  P  [WRITE  d  fll 
'  \  ( ! E.  P [RESET  E) )  =  =  >  lie.  Pci 

#I.3f  COMMAND_TASES_T.AC  = 

:nduct_then  C0MMAND_CASES_THM  ASSUME_TAC;  ,- 


The  type  definition  package  is  also  helpful  in  expressing  the  view  ftinction  neatly.  As  we  shall 
see  later,  the  view  of  a  process  is  a  partial  function  from  filenames  to  objects,  so  we  need 
some  way  of  expressing  the  faa  that,  for  certain  filenames,  the  value  of  such  a  function  is 
undefined.  Partial  ftinctions  can  be  modelled  in  HOL  in  the  following  way.  We  define  a  type 
called  privat*_stae«.  which  has  a  distinguished  element  called  UNDEF.  TVo  theorems  can 
be  proven  about  elements  of  this  type  -  one  that  the  element  UNDEF  is  not  equal  to  an  element 
of  the  form  OBJ  filanan*  and  the  other  that  the  constructor  OBJ  is  one-to^ne. 
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*-“C  r riv_o’:ace_axicm  = 

ierir;e_cype  '  ?riv_sc ac>a_axi 


Ti  ;rn 


-  c  j 


3',-^z  r. = 

r,r  :  ve_?rr.3t  rurt :  r3_di3t  ir.ct  ?rlv_3Ca::e_axi  :  ; 
r.  ;  :_-'bi_ur.def  =  i-  .‘p.  '  OBJ  p  =  VNBEF) 

ala:  priv_3Ca!;e_;ne_cne  = 

pr:ve_:  ar.st  ruc:ors_;ne_one  Priv_3Pate_axi  ;7i;  : 
pr iv_=:ate_ane_3ne  = 

. -  ! p  p ’  .  V  OBJ  p  =  OBJ  p '  )  =  ' p  =  p ' ! 

Some  constants  also  need  to  be  defined:  dom  denotes  the  relation  on  level  which  was  called 
dominates  in  Section  2.  The  properties  of  reflexivity,  antisymmetry,  transitivity  and  totality  for 
the  relation  dom  can  be  asserted  by  including  as  assumptions  to  any  goals  PO_REFL_DEF , 
PO_ANTI3YM_DEF,  PO_TRANS_DEF,  PO_TOTAL_DEF. 


?  _,n;.”r:0VM_;E.-  =  ■-  po_ar.::syn  = 

lab.  ;  ;ni  a  b  .  i;m  b  a  =  =  >  .a  =  b 

'  .a  o  -1:111  a  b  ditn  b  :  =  =  >  Icr.  a  : 

la  b.  ".dim  a  b  =  =  >  dcr.  b  a, 

The  constant  syshigh  denotes  a  level  which  is  intended  to  be  the  level  which  dominates  all 
other  levels.  This  is  asserted  by  HIGHMABK_DEF. 

r.-aw_ronstanc  ,  '  3ysr.igh '  ,  "ilevel'l;; 

HIOHMARK_DEF  =  highmark  =  Ila.  doiti  syshigh  a) 

We  also  need  a  function  called  process_level  which  associates  with  each  process  its  clearance 
level.  When  the  output  of  a  command  does  not  include  the  contents  of  a  file,  the  constant  null 
of  type  data  can  be  used  to  represent  no  information. 

r..aw_:-.r.stari:  ,  '  pr  :cess_l-evel '  ,  "ipnoess  ->  level":,-; 
i.ew_rori3tanc  ; 'riuil',  "idaCa");; 

We  define  some  auxiliary  functions  which  will  be  useful  in  defining  the  functions  next  and  out. 

MK_OBJECT_DEF  =  I-  la  b.  nik_object  a  b  =  a,b 

OBJECT_LEVEL_DEF  =  I-  !X.  object_level  X  =  SND  X 

OBJECT_DATA_DEF  =  I-  !X.  object_daCa  X  =  FST  X 

UPDATE_DEF  =  I-  If  X  s. 

update  fXs  »  (\f'.  (<f'  =  fl  =>X  I  s  f'l) 
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Next  and  out  are  supposed  to  lake  as  their  second  argument  an  action,  which  is  a  pair  consisting 
of  a  process  and  a  command.  We  would  like  to  define  next  and  out  using  HOL’s  function 
definition  facility  for  recursive  types  by  giving  the  value  returned  by  the  functions  by  cases  on 
the  form  of  the  command.  However,  HOL  will  only  allow  such  a  definition  if  the  variable  of 
type  cotnmand  is  a  single  argument  rather  than  one  contained  in  a  pair.  To  get  around  this,  the 
functions  curr'/_next  and  curry _out  are  defined  with  the  pair  of  a  process  and  a  command 
split  into  two  arguments  and  next  and  out  are  defined  (with  an  action  as  a  single  argument)  in 
terms  of  curry _next  and  curry _out.  (The  purpose  of  labouring  this  point  is  to  show  that 
such  issues  are  not  always  straightforward  in  HOL). 


-■4rr'/_r.-;xt 


p  .rEAD  file'  IS!  ' 


_''..rrv_r.e;.:r:  s  p, WRITE  i  file)  = 
i:T.  , ‘bj'ect_Ievel  ;  s  file!  !process_l-2'/el  pt  -> 
..pdete  file  r!k_;i):ecf  i  ;prccess_lev.al  p))s  : 


-  «  r  C  TT 


i  ;rr!  e  it;_ level  s  f  i  le !  )  ■  pr  rcess_level 


P' 


n  .  .i  . 


cr  pi  ;  s  Zi:  => 

■ c; - as  : ' . T- 


=  pVWRITE  i  filei  = 

i;n  :b;  eec_level !  3  f  i  le  i i  pr  ?3es3_level  p)  => 
ri'i*  1 ,  T!  .lull ,  F  ■  :  ' 

.  p  file. 

3  p'REEET  ri^et  = 

i ;n i  ibiect^level  s  f i ie ■  pr i ■es3_Ievel  p;  i> 
r.uil.T)  ■  null ,  F'  I 


yiT_IEF  I  I-  !s  3:ictiir..  viC  s  i- 
rui-ry_;4t;  3  F3T  i  TN’D 

For  the  Low  Water  Mark  Model,  information  is  not  allowed  to  flow  from  pi  to  p2  if  p2  has 
a  clearance  which  is  strictly  lower  than  pi's  clearance.  Therefore  the  security  policy  can  be 
defined  as  follows: 

?yL_DEF  =  !pl  pi. 

poL  pi  p2  =  '  iom ;proces3_level  p«;  i  iprocess_levei  pi  i 


We  also  need  to  give  a  definition  for  the  view  of  a  process.  Rushby  gives  a  construction  of  a 
canonical  view  function  for  secure  systems  which  at  first  sight  appears  a  promising  candidate  for 
the  automation  of  security  proofs.  However,  there  are  problems  with  using  such  a  construction. 
The  definition  involves  an  equivalence  relation  on  action  lists,  which  means  that  proofs  of  the 
conditions  of  the  unwinding  theorem  would  require  induction  on  action  lists.  This  defeats  the 
purpose  of  the  unwinding  theorem,  because  such  proofs  are  long  and  unwieldy,  involving  a  lot 
of  case  analysis.  Ideally  we  need  a  simple  definition  of  the  view  of  a  process  which  avoids  any 
induction  on  lists.  In  many  cases  this  is  possible.  For  the  Low  Water  Mark  Model,  we  can  define 


16 


I 


ERL-0577-RR 


the  view  of  a  process  in  a  given  stale  as  a  partial  function  from  filenames  to  the  set  of  private 
states.  The  function  is  only  defined  for  those  filenames  whose  level  is  dominated  by  that  of  the 
process  and,  in  that  case,  the  result  is  the  object  to  which  the  filename  is  mapped  in  the  given  state 
lifted  into  the  type  of  private  states.  Otherwise  the  filename  is  mapped  to  the  element  UNDEF. 


=  I-  !p  3.  view  p  3  = 

, :  .  i:m  .prr~*s3_level  p  .!  -  ;-bj 
=>  -BJ:3  I)  'JtiCE?) 


5.2  Proof  of  Security  for  the  Low  Water  Mark  Model 

To  prove  that  the  Low  Water  Mark  Model  is  secure,  we  need  to  show  that  it  satisfies  the  three 
conditions  of  the  unwinding  theorem  —  having  first  reproved  for  this  model  the  unwinding  theorem 
in  exactly  the  same  way  as  was  done  in  Section  4. 

The  first  condition  (internal  consistency  of  the  system)  and  the  second  condition  of  the  unwinding 
theorem  are  easy  to  prove  by  a  general  strategy  of  rewriting  with  definitions,  decomposing  the  goal 
using  STRIP_TAC  and  performing  case  analysis  until  all  conditional  expressions  are  removed.  The 
goal  IS  then  either  proved  by  rewriting  using  the  assumptions,  or  proved  by  finding  a  conaadiction 
among  these  assumptions.  Some  finer  manipulation  of  several  of  the  subgoals  and  assumptions 
IS  required  between  these  steps. 

The  third  condition  of  the  unwinding  theorem  is  much  more  difficult  to  prove  than  the  other 
two.  and  needs  a  more  detailed  discussion.  It  is  this  third  condition  that  requires  the  assertions 
that  dom  is  a  reflexive,  antisymmetric,  transitive  and  total  order,  and  that  syshigh  dominates 
all  other  levels.  Firstly,  the  goal  is  rewritten  and  shipped  until  the  term  obtained  is  a  universal 
quantification  on  a  variable  of  type  command.  We  can  then  use  the  tactic  COMMAND_CASES_TAC. 
which  decomposes  this  goal  into  three  subgoals  corresponding  to  the  three  different  cases  in  the 
type  definition  of  command. 
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r  EVi'r  ITE_TAC 

;  VIEW_rEF ;  HI'3HMARK_r.EF,-  ?0_3EFL_DEF; 

?■  j_AMT  I S  YM_DEF ;  F':_TRANS_DEF  ; 

f:_T';tal_eef;  ■;bject_ls'/el_eefi  ;  then 


i;:Ti  pr;'r-?3s_level  u,  EN'Dinexc  3\w, RESET  fit' 
:ET  r.e;<t  3  v.', RESET  :.t'.  . 


i  >  F  rc?ess_l^V'?I.  u  ■  SN'D  r.'SXC  3  w.  WRITE  i 
SJ.F.'ex!;  siw, 'WRITE  i 
'.'I.'EEF)  '  = 


i  ;in  '  prc.cess_iev-sl  3  iSN'Dlr.-exc  t.w, 'WRITE  .i  : : 
.EJinexC  Ciw, 'WRITE  i  f't'i  : 

■JNDEF'  !  • 

;  “la.  iom  3yshi:!r.  1  ’ 

“  !  3  .  i3tii  3  i "  : 

[  "lib.  i;:r.  3  b  .  ;;:i,  b  3  =  =  >  a  =  bj  "  ! 

[  "la  b  icm  a  b  'i-;3i  b  3  =  =  >  dom  a  c"  J 
[  "lab.  'dc:T>  a  b  =  =  -■•  d:iT\  b  a"  1 
[  Idomtpr- 3.?ss_level  'j)!SND(s  f)) 

=  >  I’BJis  fl  I  ONCEF)  )  = 

’.\f.  idem  !  pr.3cess_level  u)(SND(t  £)) 

=  -  f)  TNDEF))*  i 


"If. 

1  f  '  . 

(dom(process_level  uMSNDinext  s(w.READ  f)f')) 
'-■>BJ(nexc  3  (w,  READ  f)f')  1 


UTJDEF))  = 

(\f '  . 

(dom (process_level  u) (SNDtnext  C(w,READ  f)f')) 
OBJ (next  C(w,READ  f)f')  I 
UNDEF) ) ■ 


I 


i 
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=  =  >  i-'T.  a 


I 


r.  a  b 


.i:m  I  cr  rc-ss 


i m  b  a "  • 
level  V  sun  3  t 


f 


These  three  subgoals  all  have  the  same  form,  so  it  is  likely  that  the  same  tactics  can  be  applied 
to  each  of  them.  We  shall  just  look  at  the  second  .subgoal.  Once  the  outermost  quantifiers  are 
stripped,  this  subgoal  requires  proving  two  functions  equal.  This  can  be  done  by  showing  that  the 
results  of  the  two  functions  are  equal  for  all  values.  The  theorem  EQ_EXT  (I  -  :  £  g .  i  i  x . 
f  X  =  g  X)  =  =  >  (f  =  g))  makes  such  a  step  valid. 


THEN 


3  w, WRITE  i 


'.dom  (proire3s_I^vel  u;  EN'Diriexc  c;w, WRITE  d  =■> 

OBJ  I  next  z  w , WRITE  d  £  !  f  '  !  ! 

LTIDEF)  ' 


"It.  i ir.  ayjr.  igr.  j" 

;  "  :  1 .  dc  ~.  a  i "  ; 

!  "la  b .  d ;  .Ti  a  n  ,  d :  ai  b  a  =  =  >  i  a  =  b  i  "  ) 

'  "la  b  r.  djm  a  b  dcm  b  c  =  =  >  dam  a  c"  1 
I  "lab.  ' dom  a  b  ==>  dom  b  a’  ] 

;  ■('.£.  ■  dom  ,  pr  :'-?ss_level  ’iltSNDts  £)) 

=>  OBJ(s  f I  I  UNDEF) I  = 
'\f.  .  dom  I  pr -'Ce33_lev<al  ul'SNDtC  :i) 

r>  OBJvt  f 1  1  UNDEF) ) ■  1 


This  subgoal  can  be  simplified  by  once  again  snipping  the  outer  quantifier  and  then  applying  beta 
conversion.  It  can  then  be  rewritten  using  the  definition  of  next,  producing  a  fairly  complex  goal 
which  requires  further  case  analysis  in  order  to  be  simplified. 
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THM  ch  " X ;  :  iler.ar^.e " 


‘ :  r-?33_levei  u  ^ 

■3C3',  ■  : b]ect_lev-5 1  ■  3  f',  ■  prc'ces3_le'/el  w)  => 
■  'f'  =  r;  =>  d,  pr;c-?ss_l5vel  w)  s 


i;::, .  :b:  ect_level  ■  3  rii  :proces3_level  w)  => 
=  :  =>  d , cr jcess_level  w;  ■  s 


■'  !  -H  . 


"Is.  -i-m  a  a"  ; 

”'a  b,  d:.T  a  b  ■.  irr?  b  a  =  =  >  ,a  =  bi  "  i 
'■'a  b  3.  dr^i  a  b  -  dorr,  be  =  =  >  dem  a  c"  ) 
"  ! a  b.  '  dom  a  b  ==>  dem  b  a'  ! 

”  ■  d  rm  I  pr  ocess_lavei  a  •  SN'D  i  s  x)  ; 

=  >  d.6J!3  X)  I  ’JNDEFi  = 

'  dem  iprccess_levei  u,.SN'Dlc  x)  ) 

=  >  -'BJU  X)  ‘  iJNDEFi  ’  1 


Because  the  term  is  so  complex,  it  is  difficult  to  determine  by  human  inspection  on  what  conditions 
case  analysis  should  be  performed.  As  an  automated  reasoning  tool,  it  would  be  useful  for 
HOL  to  be  able  to  pick  out  the  relevant  conditions.  HOL  does  contain  a  built-in  tactic  called 
COND_CASES_TAC  which  performs  case  analysis  on  the  outermost  conditionals.  However,  these 
outer  conditionals  may  contain  further  conditional  expressions  which  should  firstly  have  been 
split  into  cases  to  put  the  assumptions  in  their  simplest  form.  A  tactic  called  COND_DIVE_TAC 
(written  by  M.  Ozols)  is  used  instead.  This  tactic  searches  the  term  for  the  first  condition  of  a 
conditional  which  does  not  contain  any  turther  conditional  expressions  unless  they  involve  bound 
variables  occuning  within  lambda  expressions.  It  performs  case  analysis  on  this  condition  and 
then  attempts  to  simplify  the  goal  by  applying 

BETA_TAC  and  rewriting  with  the  new  list  of  assumptions.  If  C0ND_DIVE_TAC  is  repeatedly 
applied,  all  conditional  expressions  should  be  eliminated  from  the  goal.  When  this  is  done  to  the 
above  goal.  12  subgoals  are  produced.  Case  analysis  has  in  fact  been  performed  on  five  conditions, 
which  would  normally  produce  32  subgoals  —the  tactic  automatically  solves  the  other  20  subgoals 
by  rewriting  and  beta  convenion.  An  example  of  one  of  these  12  subgoals  is  shown  below: 
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■'Is  c.  a  b  .  iir-  c  a  =  =  >  a  =  c. 

”  !  a  b  bcm  a  b  .  ii^-n  b  r  =  =  >  i-zw.  a 

"'.a  b.  '  icnf.  a  b  =  =  >  deni  b  a“  ' 


:r  :ce5S_l=vi?i 


It  can  be  seen  that  the  goal  can  only  be  proved  by  finding  a  contradiction  among  the  assumptions. 
The  overall  proof  involves  solving  many  subgoals  of  this  form.  In  the  above  case,  if  case 
analysis  is  performed  on  the  condition  occurring  in  the  first  assumption,  that  assumption  will 
either  become  UNDEF  =  OBJ(c  f)  or  OBJ (  s  f)  =  OBJ(t  f).  In  the  first  case,  the 
theorem  noc_obj_undef  can  be  used  to  rewrite  the  assumption  to  FALSE.  In  the  latter  case 
the  theorem  priv_3Cace_orie_one  can  be  used  to  show  s  f  =  t  f.  which,  together  with 
the  third  and  the  sixth  assumptions,  gives  a  contradiction. 


rrevicus  suepr;;-:: 
11  subgoals 


The  remainder  of  the  proof  consists  of  proving  the  remaining  subgoals  in  the  same  way;  by 
rewriting,  case  analysis,  further  rewriting,  finding  contradictions  among  assumptions  etc.  The 
subgoal  package  will  then  return  us  to  the  point  where  case  analysis  was  last  performed  so  that 
the  other  cases  can  be  solved.  Once  they  are  solved,  we  are  returned  to  the  previous  case  analysis 
and  so  on,  until  all  ca.ses  have  been  proved. 

The  full  proof  has  been  completed  in  HOL.  It  is  rather  long  and  unilluminating,  and  is  given  in 
Appendix  A. 
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5.3  Covert  Channels 

We  conclude  this  section  by  considering  what  happens  if  we  drop  the  assumption  that  the  relation 
dominates  is  a  total  ordering.  In  this  case,  it  is  well-known  that  the  Low  Water  Mark  Model 
c.xhtbits  covert  channels,  and  is  not  secure.  It  is  interesting  to  see  how  to  show  this  in  HOL. 

Consider  two  distinct  processes  p  and  p'  which  are  completely  unrelated  to  each  other  (so  the 
ordering  is  not  total).  Suppose  in  the  initial  state  of  the  system  f  is  a  filename  whose  level 
dominates  both  that  of  p  and  that  of  p'.  Then  both  p  and  p'  can  successfully  write  to  f. 
However,  if  p'  writes  first,  the  level  of  the  file  becomes  that  of  p'  ,  and  p  can  no  longer  write 
to  it.  Thus  process  p '  has  interfered  with  process  p,  and  so  the  system  is  not  secure. 

The  goal  is  given  to  HOL  as  follows: 


=  =  >  je  : ur*?  c  :  i  "  ;  ; 


The  proof  is  straightforward,  and  is  given  in  Appendix  A. 


6  Discussion  and  Conclusions 

HOL  has  reached  a  certain  level  of  maturity  as  a  research  tool,  but  u  ;s  only  just  beginning  to  be  used 
in  industry.  It  will  be  some  time  before  HOL  is  able  to  perform  program  verification,  and  work  in  this 
area  is  still  experimental  [6].  However,  as  we  have  seen  above.  HOL  can  be  used  with  some  success  to 
reason  about  specifications  near  the  top  level,  and  thus  to  carry  out  design  verification. 

Our  work  has  htghlighted  a  number  of  advantages  to  working  with  HOL  which  make  it  a  useful  and 
versatile  tool. 

Fhe  HOL  logic  is  expressive  since  it  is  higher  order  and  polymorphic.  As  we  have  seen,  it  allows 
theories  to  be  expressed  in  a  natural  and  succinct  way.  In  many  cases  this  facilitates  the  understanding 
>'f  mathematical  theories  and  system  specifications. 

The  soundness  and  level  of  mathematical  rigour  of  the  HOL  system  are  of  particular  benefit  for  reasoning 
about  safety  and  security  critical  systems.  Once  a  proof  is  completed,  the  user  can  have  a  high  level 
of  assurance  in  the  outcome. 

The  built-in  inference  rules  and  tactics  of  HOL  are  of  a  fine-grained  nature,  providing  the  user  with 
a  ilcxibiliiy  not  available  in  many  other  automated  rea.soning  .systems.  If  a  theorem  or  goal  does  not 
exactly  fit  the  form  required  by  a  built-in  tactic  or  inference  rule,  it  is  possible  to  carry  out  quite  delicate 
manipulation  until  the  required  form  is  achieved. 

The  ability  to  combine  tactics  and  inference  rules  using  tacticals  and  the  ML  language  also  gives  great 
flexibility  and  power  to  the  user,  who  is  able  to  create  new  tactics  designed  for  use  within  a  particular 
problem  domain,  or  for  goals  which  have  particular  characteristics. 

The  subgoal  package  allows  flexibility  in  the  way  theorems  are  proved.  HOL  can  be  used  interactively 
(as  a  proof  assistant)  to  develop  proofs  step  by  step.  Proof  steps  can  be  ’undone’,  and  the  proof  state 
saved  at  any  time,  say  if  we  need  to  prove  some  side  lemma.  We  can  also  use  it  as  a  proof  checker  by 
providing  HOL  with  a  complete  proof  and  receiving  the  proved  theorem  as  output. 

On  the  other  hand,  carrying  out  this  work  has  made  us  acutely  aware  of  some  of  the  shortcomings  of  HOL. 

HOL  is  a  difficult  system  for  a  beginner  to  learn,  especially  in  comparison  with  other  program  verifica¬ 
tion/theorem  proving  environments  such  as  mEVES  [201,  Gypsy  [21]  and  MALPAS  [22],  As  previously 
noted  the  first  taste  of  HOL  can  be  quite  frustrating,  especially  without  a  HOL  ’expert’  to  be  a  guide. 
The  new  user  must  invest  considerable  time  and  effort  before  simple  proofs  can  be  attempted. 
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The  proof  presemed  in  the  previous  section  may  have  given  the  impression  that  proofs  in  HOL  are 
straightforward  and  quickly  constructed  —  even  if  they  may  not  always  look  'natural'.  Unfortunately, 
this  is  not  the  case.  A  medium-sized  proof  such  as  the  above  is  quite  laborious  and  time-consuming  to 
construct,  involving  a  good  deal  of  proof  'exploration'.  Often,  a  vast  number  of  cases  must  be  considered, 
and  one  then  has  the  choice  of  defining  a  different  tactic  for  each  subgoal,  or  else  using  a  single  tactic 
as  a  blunt  instrument  on  all  the  subgoals.  Using  a  single  tactic  can  improve  the  readability  of  the  proof, 
but  can  be  quite  inefficient  —  some  proofs  can  take  several  minutes,  or  even  hours,  of  computation. 

A  fundamental  difficulty,  as  we  remarked  when  attempting  to  go  from  the  general  theory  of  security  to 
the  Low  Water  Mark  Model,  is  that  in  HOL  theories  are  inherited  en  bloc,  and  cannot  be  instantiated 
to  specific  instances.  Essentially,  what  is  needed  is  a  mechanism  for  the  refinement  of  types.  We  plan 
to  examine  this  question  in  future  work. 

We  also  needed  to  write  a  range  of  fine-grained  tactics  for  rewriting  assumptions,  and  manipulating  them 
in  general.  While  the  HOL  system  allows  this  to  be  done  without  difficulty,  it  is  time-consuming,  and 
we  believe  that  such  tactics  should  already  be  part  of  the  system. 
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Appendix  A: 

Detailed  HOL  Proofs 

We  give  helow.  in  full,  the  HOL  etxle  for  the  following: 

1.  auxiliary  tactics  needed  for  the  proofs; 

2.  the  proof  of  the  unwinding  theorem; 

3.  the  proof  of  security  for  the  Low  Water  Mark  Model;  and 

4.  an  example  of  a  covert  channel. 


Sjme  .^uxiliar/  Taccirs 


"cfE  AEM  TAC  r. 


:Sff-;E_TAC 


•S  i 


THEt; 


'i  C._  ..  f\  ~ 


r.d  1  .  ::^k_r.'5wasl  r.-ii  infrul-e  "1  . 

i  1  .  nik_r.'ew3si  r. -i.'  inf  rule  irl  1, 

.nSSVME_L3T^T.AC  a  :rrik_newasi  n  intrude 


-et  THl-lL_r  EV«'R:TE_?.fLE  rrer.ist  pcslscl  pcslsc:!  rtherchms 
ler  rewrircen  =  .T.ap  i\n.  el  n  rhmist)  poslscl!  in 
i-r  rewr ite_t:funs  =  ^riap  \n.  el  n  chmlsci  poslsrl 
::ap  i\Ph.  if  ~em  th  rewritten)  then 


SEWRITE_RULE 

''filter  ■  X.  not  ch=x)  rewrite_thiTis ' 'Jotherth 
el.;e  thi  thrtlrt  ;  ; 


„ e t  A3 L__R d.WR ITE _ .A;?!. _ »AC  p-_slatl  p‘tj»lst2  thmlsc  = 

F':'?_.ASSUM_LIST  i  ,  asl . 

A33:;ME_LST_T.AC  THML_PEWR:TE_RULE  asl  poElstl  poslstl  tr.l'.tt 

let  ?  EWR  ITE_.ASM_TAC  thl  = 

, as  1 , 3 ) ; goal . 

ASL_REWRITE_ASL_TAC  iupcol  (length  asl))  [I  thi  asl.g,;; 

let  A3L_REWRITE_0NE_TAC  pos  poslst  thl  = 

ASL_REWRITE_ASL_TAC  [pos]  poslsc  thl;; 

let  ASM_MP_TAC  n  m  =  ASSUM.LIST 

(\asl.  ASSUME_TAC  (MATCH_MP  (el  n  asl)  (el  m  asl.  )!;.■ 
let  A3M_LST_MP_TAC  n  ml  =  ASSUM.LIST 

(\asl.  (ASSUME.TAC  (MATCH_MP  (el  n  asl) 

(CONJL  (map  (\n.  el  n  asl)  ml)))));; 
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=  ?p:ve 

”p;_";cal  =  =  >  ir.t  arr.al  ly_r3nsister.c " , 

?  E;WRITE_TAC [ INTERNALEY.EINSISTENT.DEF; VIEW_DEF; PO_TGTAL_EEFi j  THEN 
JTRIP_TAC  THEN  REPEAT  3EN_TAC  THEN  STRIP_TAC)  THEN 
■■ ;  t-!MAN'D_CAS  ES_TAC  TH  EN 
REPEAT  3EN_TAC)  THEN 

rEWR:TE_TAC[0'JT_EEF;CUPRY_yjT_DEF]  )  THEN 
REPEAT  CTND_DIVE_TACi  THEN 

:HANGE_ASM_TAC  l  :BETA_RULE  o  T.th.  AP_THM  Ch  ■ f : ti lename" ! ) )  THENL 

7  SUBGOALS  %  I 

1-aC  READ_TAC  =  ( 

.  ASL_REWRITE_ONE_TAC  1  [2;31  (noC_obj_uncief ; pr iv_state_one_one ; 

( (GEN_ALL  o  NOT_EQ_SyM  o  SPEC_ALL)  noC_obj_undef ) 1 )  THEN 
( ASM_REWR ITE_TAC ( ] )  THEN 
(FALSE_TAC)  )  and 

WR_RES_TAC1  =  ( 

ASM_CASES_TAC  •dom(process_level  u) (object_level ( (s ; state)  :))’)  THEN 


< 
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) 


I 


f 


I 


f 


I 


I 


PEPHAT  C:ND_DIVE_TACi  THENL 

AEM_L3T_MP_TAC  6  THEN 

A3L_?EWRITE_0r]E_TAC  1  !2i  THEN 

PA1SE_TAC  ; 

AiM_L3T_MP_TAC  '  [Z-.S],  THEN 

asl_?.ewr:te_:ne_tac  i  then 

PAL3E_TAC  ; 

VSE_ASN_TAT  1 J  SPEC  "pr ; -•S5s_l-vel  v"  THEN 
A3M_LST_MP_TAC  7  THEN 

a3E_?ewrite_:he_tac  j  ii.-u;  ii,  then 

PALSE_TAC  ; 

ATM_EST_MF_TAC  ~  1 2 ; 5  J  ^  THEN 
ASL_PEWRITE_ONE_TAC  1  (21  (1)  THEN 

rALSE_TAC  1  ; 


%  The  third  condition 


let  COND_3  =  PROVE  ( 

’highmark  /\  po_re£l  /\  po_antisyin  /\  po_trans  /\  po_total  ==> 

( !  u  s  t .  1  (view  us)  »  (view  u  t ) 

=r>  lew. ((view  u  (next  s  (w,c)l)  =  (viewu  ( next  t  ( w, r ; ) ' . ) " 


> 
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AJ'M_  :.-.i=:a_TAC  ■3:r  pr  .  level  j '  SMC  3:S!:at;e>  TKEMC 

AS1._?  E>i?lTE_;'NE_TAC  1  !  1 ;  J  :  1  nct_;bT_'£ndec  ; priv_3AaAe_;ne_;r.e  ; 

■.  SEN_ALL  V  r;:T_E:'_SYM  ;■  SPEC_ALL!  n3t_3bj_ur.def  i  1  '  THE 

a.sc_?ewp:te_;me_tac  ’  :j;4:  ;;  then 

EALSE_TAC:  ; 

ASM_MF_':AC  3  7!  THEM 
ASM_1.ST_MP_TAC  1  1  :  4  :  1  ;  ^  THEM 
A..'L_=EW‘JITE_ONE_TAC  :  ,i;  THEM 

rAl..;'E_TATl  jr:i 


Vi:4  = 

ASM_;ASE3_T-AC  "din.r::  :e33_.evel  ; ;  !  SMD '  3 :  state  :  THEML 

;  AS1._.' EVv'F  ITE_  1ME_TA7  _  ,1;^!  ; ; ':_;b:_undef  ;  priv_3Cate_^r.e_:r.e  : 

:  ^  1EM_ALL  :  M1'T_EQ_SYM  :  SPEC_ALC)  not_3bj_undef  I  )  )  THE 
Asc_r£WR:TE_:r;E_TAc  '  :_;4:  then 

EALSE_TAC)  ; 

■■3E_ASM_TAT  12  'SPEC  "pr jcess_ievei  u"l)  THEN 
A3M_LST_MP_TAC  11  [  6 ; 1 1 )  THEN 
ASL_PEWRITE_ONE_TAC  3  [1;14)  (])  THEN 
FAL3E_TAC1  )  and 

Cac5  =  ( 

I ASM_CASES_TAC  "dom ( process_level  u) (SND( (s:stacei  £l)')  THENL 
[  ( ASL_REWRITE_ONE_TAC  2  (1;3J  (noC_obj_undef ;p^iv_sCate_one_one; 

(  (aEN_ALL  o  NOT_EQ_SYM  o  SPEC.ALL)  noC_obj_undef ) I )  THEN 


irECL  ;  "p  :  pr  ■  ---ra  3 "  ;  "p'  :  pro-'eS3"ll  THEN 

=ES_TAC  THEN 
_riAri^jE_AbM__  .A'v_ 

p*^  pp’  '  p'ir'.r"3S2/  3'  ri* 

p  :  process,  WRITE  a  £)1”; 
■READ  fl)  THEN 

ASM_REWRITE_;'NE_TAC  1  DEFS  THEN 

CHANGE. ASM_TAC  1  BETA.RULE  THEN 
ASM_REWRITE_ONE_TAC  1  DEFS  THEN 
CHANGE_ASM_TAC  1  BETA.RULE  THEN 
ASL_REWRITE_CNE_TAC  1  [5]  [PAIR.EQ]  THEN 
ASM_REWRITE_TAC  [ 1 ) ; ; 
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